Class masking previously relied only on the terminal flag it flips on the
source classification to avoid re-scoring it again. If a source became terminal
again (after a dedup or re-classification pass), or a partially completed run
was retried, the source could be masked a second time and gain a duplicate
masked classification. The scope now also excludes sources that already have a
masked child for the same masking algorithm, keyed on the applied_to lineage,
so a source is masked at most once per masking algorithm. This makes finishing
an interrupted run safe.

Co-Authored-By: Claude <noreply@anthropic.com>

… ran

List an algorithm for a project when it produced classifications there, and drop
the enabled-pipeline branch entirely. A configured but never-run algorithm has no
results to filter or inspect, so listing it only adds dead entries to the filter.

Removing the branch also removes the OR across the pipeline join and the
SELECT DISTINCT it forced. Measured against a local copy of production data
(roughly 834k classifications), on one of the larger projects the paginated
endpoint drops from 2206 ms to 556 ms, most of it in the pagination COUNT:
1722 ms to 275 ms.

Both remaining shapes still sequentially scan the classification and detection
tables, because no index reaches a project from a classification. The cost
therefore tracks total table size rather than project size, and improving it
further needs a denormalised project on Classification or a precomputed
per-project list.

Co-Authored-By: Claude <noreply@anthropic.com>

…lly covers

The docstring credited the lineage guard with resuming interrupted runs. It does
not: demoting a source and writing its masked child share one transaction, so a
resumed run already skips completed sources on the terminal flag alone. The guard
covers only the case the flag cannot, a source restored to terminal by a later
dedup or re-classification pass.

Also record that a taxa list is identified by primary key rather than by contents,
so editing a list in place and re-running the same mask leaves already-masked
sources scored against the earlier membership.

Co-Authored-By: Claude <noreply@anthropic.com>

The subquery returned one row per classification, so a project with a million
classifications fed a million rows into the IN clause to identify at most a few
dozen algorithms. Selecting distinct algorithm ids says what the query means.

Measured effect is small and close to run-to-run noise (median 610 ms -> 567 ms
over four runs against a local copy of production data); the change is for clarity.

Co-Authored-By: Claude <noreply@anthropic.com>

Scoping the list purely by classification authorship dropped every detector.
Localizers set Detection.detection_algorithm and never write a Classification,
so the detector behind every detection in a project disappeared from the
project's algorithm list, which renders a task_type column precisely to show
detectors next to classifiers.

Restore the enabled-pipeline join as the primary rule and admit post-processing
algorithms through a second query, restricted to algorithms with no pipeline so
the classification lookup stays off the full table. Collect the two separately
rather than OR-ing them: an OR across the pipeline join forces a SELECT DISTINCT
whose COUNT costs more than both queries together.

Measured against a local copy of production data, on the largest project the
list returns in 46 ms, versus 8 ms for the pipeline-only rule on main and 595 ms
for the authorship-only rule this replaces. The result is a superset of main:
nothing main listed is lost, and the post-processing algorithms are added.

An algorithm attached to no pipeline that only ever produced detections is still
absent, as it is on main. Catching it would mean scanning the detection table.

Co-Authored-By: Claude <noreply@anthropic.com>

The ids came from a set, whose iteration order is not a documented guarantee.
cachalot keys its cache on the generated query string, so a varying order of the
same ids would produce cache misses for identical results.

Also replaces the bound claimed for materialising the ids. "Dozens platform-wide"
was true when written but class masking creates an algorithm per source algorithm,
taxa list and reweight mode, so the count grows with use; the comment now says
where the growth comes from and when to switch to a subquery.

Co-Authored-By: Claude <noreply@anthropic.com>

The join from an algorithm to a project through its classifications emits one row
per matching classification, so the lookup shipped one id per masked classification
in the project — hundreds of thousands after a real masking run — to identify a
handful of algorithms. Adding DISTINCT collapses that to one id per algorithm in
the database. Measured effect is small on current data (the projects checked hold
hundreds to low thousands of masked classifications), but the row count was linear
in classification volume, which is exactly what this feature produces at scale.

Also document that an algorithm on a pipeline not enabled for the project stays
absent even when it has determinations there. Widening the second query to cover
that case measured roughly five times the runtime, so it is left as a known gap
matching the pipeline-join behaviour rather than folded into this change.

Co-Authored-By: Claude <noreply@anthropic.com>

…N list

The single-join form (pipelines__isnull=True combined with the classification
relation) hides the candidate algorithm ids behind an anti-join at plan time, so
Postgres sequentially scans the whole classification table to answer it. Its cost
therefore grows with the platform's total classification count, and it is scanned
cold on every cachalot invalidation, which happens on every classification write.

Split it into two steps. Collect the unpipelined algorithm ids first, as an
explicit list, then filter classifications on algorithm_id IN (...). The planner
answers that from the algorithm_id index and touches only the rows for those
algorithms. EXPLAIN on a local copy of production data confirms the plan change:
a parallel sequential scan of main_classification (about 48 ms) becomes an index
scan (about 6 ms), and the whole endpoint drops from roughly 46 ms to 12 ms. The
first query is also cheap to cache, changing only when algorithms or pipeline
links change rather than on every classification.

Clear Classification's default ordering with .order_by() before .distinct(),
otherwise the ordering columns widen the DISTINCT back to one row per
classification. The dedup test now covers this.

Co-Authored-By: Claude <noreply@anthropic.com>

The unpipelined algorithm ids are rendered verbatim into the classification
lookup's IN clause. Algorithm orders by (name, version), so the ids came out in
name order, and identical membership could produce a different id order — and so
a different SQL string and cachalot cache key — across requests. Sorting makes the
inner query cache-stable, matching the outer id list, which was already sorted for
the same reason.

Co-Authored-By: Claude <noreply@anthropic.com>

Replace the pipeline-config + unpipelined-classification hybrid in
AlgorithmViewSet with a single reusable queryset method,
Algorithm.objects.used_in_project(). The list now contains exactly the
algorithms that produced results in the project — detectors via their
detections, classifiers and post-processing algorithms via their
classifications — regardless of whether the owning pipeline is still
enabled. A superseded model version stays listed as long as its
determinations survive; an algorithm configured on an enabled pipeline
that never ran no longer appears.

Add matching OccurrenceQuerySet methods, detected_or_classified_by() and
not_detected_or_classified_by(), and route OccurrenceAlgorithmFilter
through them. The filter previously joined detections__classifications,
which returned one row per matching classification and inflated the
paginator's COUNT, and it matched only classifiers — a detector produced
no match at all. The EXISTS form counts each occurrence once and matches
both roles, so every algorithm the list shows can now filter occurrences.

Document in AGENTS.md the two query-work rules this change was built on:
run EXPLAIN (ANALYZE) before claiming a query's plan, and measure on the
largest project (surveying several sizes) rather than a single small one.

Cost note: used_in_project scans classification and detection because
neither table has a project column, so it runs ~0.1-0.6s cold and scales
with total table size until a denormalized project column exists — the
honest cost of showing exactly what ran.

Co-Authored-By: Claude <noreply@anthropic.com>

…ray the rest

The project algorithm list returns every algorithm that produced results in
the project, including superseded versions and standalone post-processing
algorithms. Serve both consumers from that one list rather than splitting
semantics: the occurrence filter needs the full historical set, and the
algorithms page now shows the same set but grays out the algorithms that are
no longer enabled for the project.

Each algorithm in the project-scoped list carries `enabled_in_project` — true
when it is on a pipeline the project has enabled, false when it only ran
historically, and null on the unscoped list where there is no project for it
to be relative to. The frontend Algorithms table dims the false rows through a
new optional `rowClassName` on the shared Table component.

Co-Authored-By: Claude <noreply@anthropic.com>

…e filter choices

The project-scoped algorithm list reverts to main's behavior — the algorithms
on the project's enabled pipelines — so a freshly configured project sees what
it can run before any job has completed. The used-only list (every algorithm
that produced results here, including superseded versions, detectors, and
standalone post-processing algorithms) moves to a new OccurrenceViewSet
sub-action at /occurrences/algorithms/, where it serves the occurrence
filter's choices so the filter never offers a zero-result value.

The enabled_in_project annotation and serializer field are dropped — the page
no longer mixes historical algorithms in, so there is nothing to gray out.

Also renames the occurrence queryset methods: detected_or_classified_by →
processed_by_algorithm (and the not_/_q variants), since the EXISTS matches
post-processing algorithms such as a size filter through the classification
leg — they neither detect nor classify. Future siblings can follow the same
family: processed_by_pipeline, processed_by_job.

Co-Authored-By: Claude <noreply@anthropic.com>

…tests

The scope-shape tests merged from main call _scoped_classifications with its
pre-idempotency two-argument signature; this branch added a third argument,
the masking algorithm whose lineage the scope excludes. A textual merge could
not catch the mismatch.

Co-Authored-By: Claude <noreply@anthropic.com>